1.2. Adding Database Copies
Creating a database
availability group is just the first step in making a database highly
available. A database that exists on one of the DAG members must be set
up with additional copies on other DAG members. Some databases may
require more copies than others.
When creating a database copy, you can specify the following details:
The name of the database you are copying.
The name of the Mailbox server that will host the database copy.
The amount of time (in minutes) to delay log replay. This sets how long to wait before the transaction logs are committed to the database copy. Setting the value for replay lag time to 0 disables the log replay delay.
The
amount of time (in minutes) for log truncation delay. This controls how
long to wait before truncating committed transaction logs. Setting the
value for truncation lag time to 0 disables the log truncation delay.
An activation
preference number. This represents the activation preference order of a
database copy when multiple databases have the same copy queue length
after a failure or outage of the active copy,
The seed
copy server. This server will be used to copy the seed database and
content indexing information to the new copy. Although this is
specified when creating a new database copy, replication always occurs
from the active database to each of the copies.
Creating databases copies
should be done according to a high-availability plan. A
high-availability plan should be created that identifies the level of
redundancy required for your environment. If JBOD (Just a Bunch of
Disks) will be used to store database files, additional copies of the
database should exist on other servers to sustain a disk failure.
You can add database copies using the Add-MailboxDatabaseCopy cmdlet or you can use the Add Mailbox Database Copy Wizard in the EMC.
1.3. Lagged Database Copies
One of the options available when configuring mailbox database
copies is to configure a lag time of up to 14 days. This lag time is
the time that the transaction logs will be held before being committed
to the database copy. By delaying committing the logs to a database
copy, you have the capability to recover the copy to a point in time
using the copy rather than having to pull data from tape-based backup
media.
Lagged database copies are deployed to protect from logical corruption. Database logical corruption and store logical corruption are the two types of logical corruption that can occur in the Exchange database.
If you use multiple database
copies and Single Item Recovery, only the extremely rare catastrophic
store logical corruption case remains unaddressed. In the following
scenarios lagged database copies can be used to recover data:
You should deploy lagged
copies to mitigate a specific risk and lagged copies are usually not
needed if you are also deploying a third-party backup solution. Lagged
copies should not be treated as another high-availability database copy
and should not be activated for the following reasons:
You lose your point-in-time recoverability.
You lose your backup copy.
Page patching is not processed on lagged copies.
Lagged copies take a long time to bring online as transaction logs are applied.
Lagged copies have storage implications as enough space must be available to store
the transaction logs for lag period. However, rather than just meeting
those requirements, it is best practice to have at least enough room
for three additional days of transaction logs, to provide for potential
truncation failures or periods of excessive log file generation.
